Conversation
Introduces a script to generate JSON-RPC API documentation from the TypeScript SDK, adds new npm scripts for API docs generation, and updates .gitignore to exclude generated API reference files.
📊 TypeScript Coverage ReportCoverage: 82.0% View detailed reportCoverage artifacts have been uploaded to this workflow run. |
Contributor
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to 23c4a48 in 2 minutes and 55 seconds. Click for details.
- Reviewed
430lines of code in2files - Skipped
1files when reviewing. - Skipped posting
6draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. sdks/ts/package.json:30
- Draft comment:
New docs scripts were added (docs:api and docs:all). Ensure the generated API docs folder is properly ignored (e.g. via .gitignore) if it’s not meant to be committed. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a speculative comment - it says "if it's not meant to be committed". We don't know if these docs are meant to be committed or not. The comment is asking the author to verify something rather than pointing out a definite issue. We also don't have visibility into the .gitignore file or the generate-api-docs.js script to know what the intended behavior is. The comment raises a valid point about generated files potentially needing to be gitignored. Not having proper gitignore settings could lead to unwanted files being committed. While the concern is valid, the comment is speculative and asking for verification rather than pointing out a definite issue. We don't have enough context to know if this is actually a problem. Delete this comment because it's speculative and asks for verification rather than pointing out a definite issue that needs fixing.
2. sdks/ts/scripts/generate-api-docs.js:40
- Draft comment:
The regex for extracting the properties table is brittle and assumes a fixed markdown format. Consider documenting the expected structure or making the parser more resilient. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment raises a valid concern about code maintainability. The regex is indeed quite specific and could break if the TypeDoc output format changes. However, this is a documentation generation script, not core application logic. The format of TypeDoc output is fairly standardized and unlikely to change frequently. The comment doesn't suggest a clear alternative approach. The comment identifies a real technical debt issue, but may not be actionable enough. What specific improvements would make the parser more resilient? Just documenting the expected structure doesn't solve the brittleness. While the regex is brittle, this is acceptable for a documentation tool where the input format is controlled and stable. The complexity of making it more robust may not be worth the effort. The comment should be removed. While technically correct about the brittleness, it doesn't provide actionable suggestions and the current approach is reasonable for a documentation generation script.
3. sdks/ts/scripts/generate-api-docs.js:119
- Draft comment:
The regex used to extract the return type (e.g./Promise\<\[(\w+)\]/) is tightly coupled to a specific TypeDoc format and may break if that format changes. Consider a more robust approach. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment raises a valid concern about maintainability - the regex is indeed brittle and assumes a very specific markdown format. However, this is a documentation generation script, not core application logic. Some degree of coupling to the documentation tool's output format is inevitable. The current approach, while not perfect, is simple and gets the job done. A more robust approach would likely add significant complexity for minimal benefit. The comment correctly identifies a potential maintenance issue. If TypeDoc changes its output format, this script would break. However, this is an internal documentation generation script where some coupling to TypeDoc's format is expected. The suggested "more robust approach" is vague and would likely overcomplicate things. While technically correct, the comment suggests adding complexity to solve a hypothetical future problem in a documentation tool. The current simple approach is adequate for this use case.
4. sdks/ts/scripts/generate-api-docs.js:188
- Draft comment:
Defaulting to an empty array for 'params' when no parameters exist might be inconsistent with common JSON-RPC usage (which typically uses an empty object {}). - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While both [] and {} are technically valid in JSON-RPC 2.0, {} is more commonly used in practice. However, this is a style preference rather than a correctness issue. The code will work fine either way. The comment is suggesting a change that isn't strictly necessary. The comment raises a valid point about common JSON-RPC usage patterns, but it's more of a style preference than a functional issue. Since both formats are valid according to the JSON-RPC 2.0 spec, and the current code works correctly, this change isn't critical enough to warrant a comment. The comment should be removed since it suggests a style change rather than fixing a real issue, and both formats are valid according to the spec.
5. sdks/ts/scripts/generate-api-docs.js:310
- Draft comment:
The list of RPC methods is hardcoded. This approach requires manual updates when new methods are added. Consider dynamically deriving the list from parsed methods for improved maintainability. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While it's true that the list is hardcoded, there are good reasons for this: 1. The RPC methods need to be carefully curated - not all SDK methods should be exposed as RPC endpoints 2. The code already handles missing methods gracefully with a warning at line 333 3. The hardcoded list serves as documentation of what methods are intentionally exposed 4. Making it dynamic could expose internal methods unintentionally The comment identifies a real maintainability concern - when new RPC methods are added, developers need to remember to update this list. However, having an explicit list of exposed RPC methods is a security feature and helps with API stability. The minor maintenance burden is worth the control and clarity it provides. The hardcoded list is intentional and beneficial, despite the small maintenance cost. The comment should be deleted.
6. sdks/ts/scripts/generate-api-docs.js:407
- Draft comment:
The file lacks a newline at the end. Adding a trailing newline can help avoid potential issues with some tools and linters. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
Workflow ID: wflow_hy0Wg0ce9HvcIduL
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
dev-jodee
approved these changes
Sep 5, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduces a script to generate JSON-RPC API fumadocs documentation from the TypeScript SDK typedocs, and updates .gitignore to exclude generated API reference files (they will be migrated to the launch fumadocs page).
Example Use
Example Output
title: estimateTransactionFee
description: Estimates the transaction fee in both lamports and the specified token.
JSON-RPC Request
{ "jsonrpc": "2.0", "id": 1, "method": "estimateTransactionFee", "params": { "transaction": "base64EncodedTransaction", "fee_token": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" } }JSON-RPC Response
{ "jsonrpc": "2.0", "id": 1, "result": { "fee_in_lamports": 5000, "fee_in_token": 1000000, "payment_address": "3Z1Ef7YaxK8oUMoi6exf7wYZjZKWJJsrzJXSt1c3qrDE", "signer_pubkey": "3Z1Ef7YaxK8oUMoi6exf7wYZjZKWJJsrzJXSt1c3qrDE" } }cURL Example
TypeScript SDK
Important
Adds a script to generate JSON-RPC API documentation from TypeScript SDK typedocs and updates scripts in
package.json.docs:apianddocs:allscripts inpackage.jsonto generate JSON-RPC API docs.generate-api-docs.jsto parse TypeDoc output and generate JSON-RPC API documentation.generate-api-docs.js.docs/api-reference-generated..gitignoreto exclude generated API reference files.This description was created by
for 23c4a48. You can customize this summary. It will automatically update as commits are pushed.